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ABSTRACT 



An apparatus for and method of utilizing an Internet termi- 
nal coupled to the world wide web to create multiple 
applications for accessing an existing proprietary data base 
management system. A^yharmcitoacmgfrfa^ity^ 
<deyelopergto£debug &tbc-^ 
.capabilitpwMchTp r^ 
'traeeggfclh^T^ 

The trace process is divided into two major components. A 
generic trlce^forfgatting^moduR processes all trace results 
from various applications into <agstandaro^zed^fonnatlfor 
storage and subsequent use. The second component is a 
generic policy in which the developer can ( prescn tlthegtracet 
'paramejen ^of^a ^ 

c i2ea^f6Qn. To store trace information from a plurality of 
applications into a common storage area, each of the appli- 
cations is provided with a common identifier within the trace 
parameters. 

24 Claims, 20 Drawing Sheets 
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BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The preseQt invention generally relates to data base man- 
agement systems and more particularly relates to enhance- 
ments for dynamic tracing within an environment wherein 
users request information from the data base management 
system via the Internet. 

2. Description of the Prior Art 

Data base management systems are well known in the 
data processing art. Such commercial systems have been in 
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general use for more than 20 years. One of ihe most 
successful data base management systems is available from 
Unisys Corporation and is called the MAPPER-*data base 
management system. The MAPPER system can be reviewed 
using the MAPPER User's Guide which may be obtained 
from Unisys Corporation. 

The MAPPER system, which runs on proprietary hard- 
ware also available from Unisys Corporation, provides a 
way for clients to partition data bases into structures called 
cabinets, drawers, and reports as a way to offer a more 
tangible format. The MAPPER data base manager utilizes 
various predefined high-level instructions whereby the data 
base user may manipulate the data base to generate human- 
readable data presentations. The user is permitted to prepare 
lists of the various predefined high-level instructions into 
data base manager programs called "MAPPER Runs". Thus, 
users of the MAPPER system may create, modify, and add 
to a given data base and also generate periodic and aperiodic 
updated reports using various MAPPER Runs. 

However, with the MAPPER system, as well as with 
similar proprietary data base management systems, the user 
must interface with the data base using a terminal coupled 
directly to the proprietary system and must access and 
manipulate the data using the MAPPER command language 
of MAPPER. Ordinarily, that means that the user must either 
be co-located with the hardware which hosts the data base 
management system or must be coupled to that hardware 
through dedicated data links. Furthermore, the user usually 
needs to be schooled in the command language of MAPPER 
(or other proprietary data base management system) to be 
capable of generating MAPPER Runs. 

Since the advent of large scale, dedicated, proprietary data 
base management systems, the internet or world wide web 
has come into being. Unlike closed proprietary data base 
management systems, the internet has become a world wide 
bulletin board, permitting all to achieve nearly equal access 
using a wide variety of hardware, software, and communi- 
cation protocols. Even though some standardization has 
developed, one of the important characteristics of the world 
wide web is its ability to constantly accept new and emerg- 
ing techniques within a global framework. Many current 
users of the internet have utilized several generations of 
hardware and software from a wide variety of suppliers from 
all over the world. It is not uncommon for current day young 
children to have ready access to the world wide web and to 
have substantial experience in data access using the internet. 

Thus, the major advantage of the internet is its univer- 
sality. Nearly anyone, anywhere can become a user. That 
means that virtually all persons are potentially internet users 
without the need for specialized training and/or proprietary 
hardware and software. One can readily see that providing 
access to a proprietary data base management system, such 
as MAPPER, through the internet would yield an extremely 
inexpensive and universally available means for accessing 
the data which it contains and such access would be without 
the need for considerable specialized training. 

There are two basic problems with permitting internet 
access to a proprietary data base. The first is a matter of 
security. Because the internet is basically a means to publish 
information, great care must be taken to avoid intentional or 
inadvertent access to certain data by unauthorized internet 
users. In practice this is substantially complicated by the 
need to provide various levels of authorization to internet 
users to take full advantage of the technique. For example, 
one might have a first level involving no special security 
features available to any internet user. A second level might 
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be for specific customers, whereas a third level might be 
authorized only for employees. One or more fourth levels of 
security might be available for officers or others having 
specialized data access needs. 

s Existing data base managers have security systems, of 
course. However, because of the physical security with a 
proprietary system, a certain degree of security is inherent in 
the limited access. On the other hand, access via the internet 
is virtually unlimited which makes the security issue much 

10 more acute. 

Current day security systems involving the world wide 
web involve the presentation of a user-id and password. 
Typically, this user-id and password either provides access 
or denies access in a binary fashion. To offer multiple levels 

15 of secure access using these techniques would be extraor- 
dinarily expensive and require the duplication of entire 
databases and or substantial portions thereof. In general, the 
advantages of utilizing the world wide web in this fashion to 
access a proprietary data base are directly dependent upon 

20 the accuracy and precision of the security system involved. 
The second major problem is imposed by the internet 
protocol itself. One of the characteristics of the internet 
which makes it so universal is that any single transaction in 

25 HTML language combines a single transfer (or request) 
from a user coupled with a single response from the internet 
server. In general, there is no means for linking multiple 
transfers (or requests) and multiple responses. In this 
manner, the internet utilizes a transaction model which may 

30 be referred to as "stateless". This limitation ensures that the 
internet, its users, and its servers remain sufficiently inde- 
pendent during operation that no one entity or group of 
entities can unduly delay or "hang-up" the communications 
system or any of its major components. Each transmission 

35 results in a termination of the transaction. Thus, there is no 
general purpose means to link data from one internet trans- 
action to another, even though in certain specialized appli- 
cations limited amounts of data may be coupled using 
"cookies" or via attaching data to a specific HTML screen. 

40 However, some of the most powerful data base manage- 
ment functions or services of necessity rely on coupling 
function attributes and data from one transaction to another 
in dialog fashion. In fact this linking is of the essence of 
Mapper Runs which assume change of state from one 

45 command language statement to the next. True statelessness 
from a first MAPPER command to the next or subsequent 
MAPPER command would preclude much of the power of 
MAPPER (or any other modern data base management 
system) as a data base management tool and would eliminate 

5 0 data base management as we now know it. 

Providing the system with the capability to save the 
needed information from transaction to transaction, permits 
applications to be developed for a true dialog-type interface 
between the legacy data base management system and an 

ss Internet terminal. As a result, it becomes important to offer 
certain useful debug features. However, typical run-time 
tracing is available only on an object-by-object basis. This 
makes debug of an application employing multiple compo- 
nents extremely difficult to utilize. Furthermore, typical 

60 run-time tracing facility need to be specifically developed 
for each component to be traced. 

SUMMARY OF THE INVENTION 

The present invention overcomes the disadvantages of the 
65 prior art by providing a method of and apparatus for debug 
of multiple component applications for access of a legacy 
data base management system via Internet terminal. In order 



06/10/2004, EAST Version: 1.4.1 



US 6,708,173 Bl 

5 6 

to permit any such access, the present invention must first A repository is established to store the state of the service 

provide an interface herein referred to generically as a request sequence. As such, the repository can store interme- 

gateway, which translates transaction data transferred from diate requests and responses, as well as other data associated 

the user over the internet in HTML format into a format from with the service request sequence. Thus, the repository 

which data base management system commands and inputs 5 buffers commands, data, and intermediate products utilized 

may be generated. The gateway must also convert the data m formatting subsequent data base management service 

base management system responses and outputs for usage on requests and i n formatting subsequent data to be available to 

the user's internet terminal. Thus, as a minimum, the gate- the user ' s browser - 

way must make these format and protocol conversions. In The transaction data in HTML format received by the 

the preferred embodiment, a number of gateways reside in 10 serv u er from the ^ Wlt ^ l u he state "formation stored 

the web server coupled to the user via the world wide web m lhe repository, are processed by a service handler into a 

j , j . • * j * i_ * * sequence of service requests in the command language or 

and coupled to proprietary data base management system. .u j * u . » » 

r r r J the data base management system. 

To make access to a proprietary data base by internet users ^ h me ^ Qf me sitory to store the state of the 

practical, a sophisticated security system is required to service request sequence, the service handler to execute data 
prevent intentional or inadvertent unauthorized access to the 15 ^ m ^ ^ mm ^ me world wide web ^ is 
sensitive data of an organization. As discussed above, such Me q{ erforming each and every data base manage . 
a security system should provide multiple levels of access to mem avaikble tQ u ^ inchldi a ^ from a 
accommodate a variety of authorized user categories. In the rieta terminal havi a ded i C ated communication hnk 
preferred embodiment of the present invention rather than whicfa ^ with me proprietary dala base manage- 
defining several levels of data classification, the different 20 ^ g hardware and softwarc In addition> the data 
classes of users are managed by identifying a secunty profile base mariagemeDt system ^ at the world wide web 
as a portion of those service requests requiring access to [& ^ {Q acco ^ ^ without exterjsive train- 
secure data. Thus, the secunty profile accompanies the m me command i aaguage 0 f the data base 
data/service to be accessed. User information is correlated to management system 

me access permitted. 25 ^ ^ ^ ^ mode of ^ t 

accessed by one or more of the several classes of user. mV ention, me Co ol ICE Data Wizard Join Service provides 

In the preferred mode of practicing the present invention, a web based mterfacc tbat a dcV eloper to create a web 
a given user is correlated with a security profile. Upon based service that joins tables from MAPPER Reports, 
preparation of the service request which provides internet MAPPER runs, databases that are ODBC compliant, and 
access to a given portion of the data base, the service request many RDMS) md MAPPER. This service renders the result- 
developer specifies which security profiles are permitted mg table t0 the web -j^ result can be ren dercd to the web 
access to the data or a portion thereof. The service request either by a Cool ICE Script or by an Active Server p age 
developer can subsequently modify the accessibility of any To ^ the developer of such applications, the system of 
security profile. The utility of the system is greatly enhanced ^ fcrred modc of the nt mvcntiorj employs a 
by permitting the service request developer to provide tradn fadH « UTrace » which allows components 
access to predefined portions of the data rather than being ffom 0Qe of more applications to write trace information to 
limited to permit or deny access to all of the data involved. a common ^ fik Utrace fe implemeilted both a 

The present invention also permits the system to modify COM out-of-process executable (Utrace.exe), and a DLL 

and redefine the security profiles during operation. In accor- 4Q (Utracer.DLL). The Utrace.exe provides the implementation 

dance with the preferred technique, the system administrator 0 f a COM component that performs the actual file writes to 

can access an individual user and directly modify the the trace file on behalf of the application. The Utrace 

security profile just for that user. This is accomplished by component implements a new COM interface called 

calling up an HTML page for the selected user showing the IUTrace that provides the interface to the tracing services, 

security profile of record. The system administrator makes 45 while the IUTrace interface is directly callable from any 

changes as appropriate. The Data Wizard Security Service COM client, a helper class (CUTracer) to this interface is 

generates script associated with the security profile change used to provide additional services for an application. The 

which provides the selected user with the new set of access Utracer.DLL provides the CUTracer tracing helper class that 

privileges. offers services for application trace configuration and data 

Whereas the gateway and the security system are the 50 formatting, 

minimum necessary to permit the most rudimentary form of The present invention separates the tracing process into 

communication between the internet terminal of the user and two processes. The trace formatting provides a standardized 

the proprietary data base management system, as explained facility for generically formatting all trace attributes in a 

above, the internet is a "stateless 1 ' communication system; common maimer.'^eneric^fo 

the addition of the gateway and the security system do not 55 suchatems:;as^BIDr"Thread^© 

change this statelessness. To unleash the real power of the usefiiMo^th'e-applie^^ This 

data base management system, the communication protocol common formatting prepares all attributes for storage and 

between the data base and the user requires functional access. 

interaction between the various data transfers. The second process is called trace policy. This identifies 

The present invention adds security management and state 60 the actual trace operations to be performed. The trace policy 

management to this environment. Instead of considering provides a mechanism for an application to categorize 

each transfer from the internet user coupled with the corre- application specific information to be traced. It is the appli- 

sponding server response as an isolated transaction event as cation developer's responsibility to define the tracing policy 

defined by the world wide web, one or more related service for the particular application using the generic trace policy 

requests may be functionally associated in a service request 65 feature provided by this invention^ flTus'trace p o l i cy~ig 

sequence as defined by the data base management system Tsj^cific-ip-a-c^^ 

into a dialog. pojiejitg*ttffi^ tracing ^ 



06/10/2004, EAST Version: 1.4.1 



US 6,71 

7 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other objects of the present invention and many of the 
attendant advantages of the present invention will be readily 
appreciated as the same becomes better understood by 
reference to the following detailed description when con- 
sidered in connection with the accompanying drawings, in 
which like reference numerals designate like parts through- 
out the figures thereof and wherein: 

FIG. 1 is pictographic view of the Cool ICE system 
coupled between a user on the world wide web and an 
existing proprietary data base management system; 

FIG. 2 is a schematic drawing showing the operation of a 
multi-level security system in accordance with the preferred 
embodiment of the present invention; 

FIG. 3 is a pictographic view of the hardware of the 
preferred embodiment; 

FIG. 4 is a semi-schematic diagram of the operation of the 
Cool ICE system; 

FIG. 5 is an overall schematic view of the software of the 
Cool ICE system; 

FIG. 6 is a schematic view of a service request; 

FIG. 7 shows a schematic view of a service request 
sequence; 

FIG. 8 is a diagrammatic comparison between a dialog- 
based structure and a service -based structure; 

FIG. 9 is a detailed diagram of the storage and utilization 
of state information within the repository; 

FIG. 10 is a detailed diagram showing security profile 
verification during a service request; 

FIG. 11 is a flow diagram showing the operation of the 
Cool ICE Data Wizard; 

FIG. 12 is a detailed flow diagram showing the basic Data 
Wizard functions; 

FIG. 13 is a flow diagram showing the role of the Cool 
ICE Administration module; 

FIG. 14 is a diagram showing utilization of the Cool ICE 
Data Wizard; 

FIG. 15 is a flow diagram showing operation of the Data 
Wizard Join Service; 

FIG. 16 is a detailed flow diagram for Join Service; 

FIG. 17 is a detailed flow diagram of the Utrace archi- 
tecture; 

FIG. 18 is a detailed table of the registry settings for 
initially tracing for an application; 

FIG. 19 is a flow chart showing the generic trace process; 

FIG. 20A is a table showing typical definitions for policy 
trace flags; and 

FIG. 20B is a table showing a typical run- time trace call. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

The present invention is described in accordance with 
several preferred embodiments which are to be viewed as 
illustrative without being limiting. These several preferred 
embodiments are based upon MAPPER data base manage- 
ment system, and the Cool ICE software components, all 
available from Unisys Corporation. 

FIG. 1 is an overall pictographic representation of a 
system 10 permitting access to a proprietary data base 
management system via an internet terminal. Existing data 
bases and applications 12 represents commercially available 
hardware and software systems which typically provide 
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select users with access to proprietary data and data base 
management functions. In the preferred embodiment, exist- 
ing data bases and applications 12 represents one or more 
data bases prepared using MAPPER data base management 

5 system, all available from Unisys Corporation. Historically, 
existing data bases and applications 12 could only be 
accessed from a dedicated, direct terminal link, either physi- 
cally co-located with the other system elements or connected 
thereto via a secured dedicated link. 

1Q With the preferred mode of the present invention, com- 
munication between new web application terminal 14 and 
existing data bases and applications 12 is facilitated. As 
discussed above, this permits nearly universal access by 
users world wide without specialized hardware and/or user 
training. The user effects the access using standardized 
HTML transaction language through world wide web link 16 
to the Cool ICE system 20, which serves as a world wide 
web server to world wide web link 16. 

Cool ICE system 20 appears to existing data bases and 
applications 12 as a data base management system propri- 
etary user terminal over dedicated link 18. Oftentimes, 
dedicated link 18 is an intranet or other localized link. Cool 
ICE system 20 is currently available in commercial form as 
Cool ICE Revision Level 2.1 from Unisys Corporation. 

25 FIG. 2 is a basic schematic diagram of security system 22 
of the preferred mode of the present invention. By way of 
example, there are four categories of service defined, each 
with its own functionality and portion of the data base. 
Service A 36 contains data and functions which should only 

30 be made available to customers. Service B 38 contains data 
and functions which should only be made available to 
customers or employees. Service C 40 contains data and 
functions which should only be made available to 
employees, and Service D 42, containing the least restrictive 

35 data and functions may be made available to anyone, includ- 
ing the general public. 

In a typical application, Service D 42 might contain the 
general home page information of the enterprise. It will 
consist of only the most public of information. It is likely to 

40 include the name, address, e-mail address, and phone num- 
ber of the enterprise, along with the most public of the 
business details. Usually, Service D 42 would include means 
of presenting the information in a sufficiently interesting 
way to entice the most casual of the public user to make 

45 further inquiry and thus become more involved with the 
objectives of the enterprise. Service D 42 represents the 
lowest level of security with data and functions available to 
all. 

Service C 40 is potentially the highest level of classifi- 

50 cation. It contains data and functions which can be made 
available only to employees. In actual practice, this might 
entail a number of sub levels corresponding to the various 
levels of authority of the various employees. However, some 
services may be so sensitive that the enterprise decides not 

55 to provide any access via the internet. This might include 
such things as strategic planning data and tools, advanced 
financial predictions, specific information regarding indi- 
vidual employees, marketing plans, etc. The penalty for this 
extreme security measure is that even authorized individuals 

60 are prohibited from accessing these services via the internet, 
and they must take the trouble to achieve access via an 
old-fashioned dedicated link. 

Customers and employees may share access to Service B 
38. Nevertheless, these data and functions are sufficiently 

65 sensitive that they are not made public. Service B 38 likely 
provides access to product specifications, delivery schedules 
and quantities, and pricing. 
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For customer access only is Service A 36, One would 
expect marketing information, along with specific account 
information, to be available here. 

These four service levels (i.e., Service A 36, Service B 38, 
Service C 40, and Service D 42) are regulated in accordance 
with three security profiles. The lowest level of security does 
not require a security profile, because any member of the 
general public may be granted access. This can be readily 
seen as guest category 28 (e.g., a member of the public) can 
directly access Service D 42. Of course, all other categories 
of user may also directly access Service D 42, because all 
members of the more restrictive categories (e.g., customers 
and employees) are also members of the general public (i.e., 
the least restrictive category). 

Security Profile #1, 30 permits access to Service A 36 if 
and only if the requester seeking access is a customer and 
therefore a member of customer category 24. Members of 
customer category 24 need to identify themselves with a 
customer identification code in order to gain access. The 
assigning and processing of such identification codes are 
well known to those of skill in the art. 

Similarly, Security Profile #3, 34 permits access to Ser- 
vice C 40 if and only if the requestor seeking access is an 
employee and therefore a member of employee category 26. 
Security Profile #2, 32 permits access to Service B 38 to 
requesters from either customer category 24 or employee 
category 26, upon receipt of a customer identification code 
or an employee identification code. A more detailed descrip- 
tion of the security system of the preferred mode of the 
present invention is found below. 

FIG. 3 is a pictorial diagram of hardware suite 44 of the 
preferred embodiment of the present invention. The client 
interfaces with the system via internet terminal 46. Terminal 
46 is an industry compatible, personalized computer having 
a suitable web browser, all being readily available commer- 
cial products. Internet terminal 46 communicates over world 
wide web access 48 using standardized HTML protocol. 

The Cool ICE system is resident in web server 50, which 
is coupled to internet terminal 46 via world wide web access 
48. In the preferred mode, web server 50 is owned and 
operated by the enterprise owning and controlling the pro- 
prietary data base management system. Web server 50 may 
serve as the internet access provider for internet terminal 46. 
Web server 50 may be a remote server site on the internet if 
the shown client has a different internet access provider. This 
would ordinarily occur if the shown client were a customer 
or guest. 

In addition to being coupled to world wide web access 48, 
web server 50 7 containing the Cool ICE system, can be 
coupled to network 52 of the enterprise as shown. Network 
52 provides the system with communication for additional 
enterprise business purposes. Thus, The Cool ICE applica- 
tion or web server 50 and others granted access may 
communicate via network 52 within the physical security 
provided by the enterprise. Also coupled to network 52 is 
departmental server 58 having departmental server storage 
facility 60. Additional departmental servers (not shown) 
may be coupled to network 52. The enterprise data and 
enterprise data base management service functionality typi- 
cally resides within enterprise server 54, departmental server 
58, and any other departmental servers (not shown). Normal 
operation in accordance with the prior art would provide 
access to this data and data base management functionality 
via network 52 to users directly coupled to network 52. 

In the preferred mode of the present invention, access to 
this data and data base management functionality is also 
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provided to users (e.g., internet terminal 46) not directly 
coupled to network 52, but indirectly coupled to network 52 
via web server 50 and the Cool ICE Server application 
components. As explained below in more detail, web server 

5 50 provides this access utilizing the Cool ICE system 
resident in web server 50. 

FIG. 4 is pictographic view of the system of FIG. 3 with 
particular detail showing the organization and operation of 
the Cool ICE system 62, which is resident in the web server 

10 (see also FIG. 3). In this view, the client accesses the data 
base management system within the enterprise via internet 
terminal 54 which is coupled to the web server 68 by world 
wide web path 66. Again, the internet terminal 54 is pref- 
erably an industry standard computer utilizing a commer- 

15 cially available web browser. 

The basic request/response format of the Cool ICE system 
involves a "service" (defined in greater detail below) which 
is an object of the Cool ICE system. The service is a 
predefined operation or related sequence of operations 

20 which provide the client with a desired static or dynamic 
result. The services are categorized by the language in which 
they were developed. Whereas all services are developed 
with client-side scripting which is compatible with internet 
terminal 54 (e.g., HTML), the server-side scripting defines 

25 the service category. Native services utilize Cool ICE script 
for all server-side scripting. On the other hand, open services 
may have server-side scripting in a variety of common 
commercial languages including Jscript, VBScript, ActiveX 
controls, and HTML. Because native services are developed 

30 in the Cool ICE script (run) language, greater development 
flexibility and variety are available with this technique. 

Web server 68 provides processor 70 for Active Server 
Pages (ASP J s) which have been developed as open services 

35 72 and a Default ASP 73 for invoking native services. After 
the appropriate decoding within a native or open service, a 
call to the necessary Cool ICE object 74 is initiated as 
shown. The selected service is processed by the Cool ICE 
engine 76. 

40 Repository 80 is a storage resource for long term storage 
of the Cool ICE service scripts and short term storage of the 
state of a particular service. Further details concerning 
repository 80 may be found by consulting the above 
referenced, commonly-assigned, co-pending U.S. Patent 

45 Application. In the preferred mode of the present invention, 
the service scripts stored in repository 80 are typically very 
similar to mapper runs as described above. For a more 
detailed description of mapper runs, Classic MAPPER User 
Manual is available from Unisys Corporation and incorpo- 

50 rated herein by reference. 

Cool ICE engine 76 sequences these previously stored 
command statements and can use them to communicate via 
network 84 with other data base management system(s) 
(e.g., MAPPER) resident on enterprise server 86 and/or 

55 departmental server 88. The storage capability of repository 
80 is utilized by Cool ICE engine 76 to store the state and 
intermediate products of each service until the processing 
sequence has been completed. Following completion, Cool 
ICE engine 76 retrieves the intermediate products from 

<So repository 80 and formats the output response to the client, 
which is transferred to internet terminal 54 via web server 68 
and world wide web path 66. 

Cool ICE Administrator 82 is available for coordination 
of the operation of Cool ICE system 62 and thus can resolve 

65 conflicts, set run-time priorities, deal with security issues, 
and serve as a developmental resource. Graphing engine 78 
is available to efficiently provide graphical representations 
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of data to be a part of the response of a service. This tends 
to be a particularly useful utility, because many of the 
existing data base management systems have relatively 
sparse resources for graphical presentation of data. 

The combination of Cool ICE object 74, Cool ICE engine 
76, and repository 80 permits a rather simplistic service 
request from internet terminal 54 in dialog format to initiate 
a rather complex series of data base management system 
functions. In doing so, Cool ICE engine 76 emulates an 
intranet user of the data base management system(s) resident 
on enterprise server 86 and/or departmental server 88. This 
emulation is only made possible, because repository 80 
stores sequences of command language statements (i.e., the 
logic of the service request) and intermediate products (i.e., 
the state of the service request). It is these functions which 
are not available in ordinary dialog on the world wide web 
and are therefore not even defined in that environment. 

FIG. 5 is a schematic diagram 90 of the software com- 
ponents of the Cool ICE system and the software compo- 
nents to which it interfaces in the preferred mode of the 
present invention. The client user of the Cool ICE system 
interfaces directly with web browser 92 which is resident on 
internet terminal 54 (see also FIG. 4). Web browser 92 is a 
commercially available browser. The only special require- 
ment of web browser 92 is that it be capable of supporting 
frames. 

Web browser 92 communicates with web server software 
96 via internet standard protocol using HTML language 
using world wide web path 94. Web server software 96 is 
also commercially available software, which is, of course, 
appropriate for the web server host hardware configuration. 
In the preferred mode of the present invention, web server 
software 96 is hosted on Windows ITS-based server avail- 
able from Microsoft Corporation. 

Cool ICE system software 98 consists of Cool ICE Object 
{ the gateway) 100, Cool ICE service handler 102, Cool ICE 
administration 104, Cool ICE repository 106, and Cool ICE 
Scripting Engine 108. It is these five software modules 
which establish and maintain an interface to web server 
software 96 using corn interfaces and interface to Cool 
ICE's internal and external data base management system. 

Cool ICE object 100 is the interface between standard, 
commercially available, web server software 96 and the 
internal Cool ICE system scripting engine with its language 
and logic facilities. As such, Cool ICE object 100 translates 
the dialog format, incoming HTML service request into 
internal Cool ICE requests for service. Intrinsic in this 
translation is a determination of the service category (see 
also FIG. 4) — that is whether the service request is a native 
service (i.e., with a default Cool ICE server-side scripting) 
or an open service (i.e., with server-side scripting in another 
commercial language using the Cool ICE object 100). 

The service request, received from Cool ICE object 100, 
is utilized by Cool ICE service handler 102 to request the 
corresponding service action script from Cool ICE reposi- 
tory 106 and to open temporary state storage using Cool ICE 
repository 106. Cool ICE service handler 102 sequences 
through the service input variables of the object received 
from Cool ICE object 100 and transfers each to Cool ICE 
repository 106 for temporary storage until completion of the 
service request. Cool ICE service handler 102 retrieves the 
intermediate products from Cool ICE repository 106 upon 
completion of the service request and formulates the Cool 
ICE response for transfer to browser 92 via web server 
software 96 and world wide web path 94. 

Cool ICE administration 104 implements automatic and 
manual control of the process. It provides for record 
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keeping, for resolution of certain security issues, and for 
development of further Cool ICE objects. Interconnect 110 
and interconnect 112 are software interface modules for 
communicating over the enterprise network (see also FIG. 

5 4). These modules are dependent upon the remaining pro- 
prietary hardware and software elements coupled to the 
enterprise network system. In the preferred mode of the 
present invention, these are commercially available from 
Unisys Corporation. 

10 FIG. 6 is a schematic diagram 116 showing the processing 
of a service request by the Cool ICE system. Screen 118 is 
the view as seen by the client or user at an internet terminal 
(see also FIG. 4). This screen is produced by the commer- 
cially available browser 120 selected by the user. Any such 

15 industry standard browser is suitable, if it has the capability 
to handle frames. ^eaangiiagejQf^ 
'HyJ|[rli£]£^ 

uesident.seryer! The components of the URL are as follows. 
In many instances, this will simply be the internet access 

2Q provider of the internet terminal, as when the internet 
terminal is owned by the enterprise and the user is an 
employee. However, when the user is not an employee and 
the internet terminal is not necessarily owned by the 
enterprise, it becomes more likely that hyperlinks 126 iden- 

25 tifies a remotely located server. 

Icon 122 is a means of expressly identifying a particular 
service request. Such use of an icon is deemed to be unique. 
Additional detail concerning this use of an icon is available 
in the above identified, commonly assigned, co-pending 

30 U.S. Patent application. Window area 128 provides for the 
entry of any necessary or helpful input parameters. Not 
shown are possible prompts for entry of this data, which may 
be defined at the time of service request development. 
Submit button provides the user with a convenient means to 

35 transmit the service request to the web server in which the 
Cool ICE system is resident. 

Upon "clicking on" submit button 130, screen 118 is 
transmitted to web server 136 via world wide web path 132. 
As discussed above, world wide web path 132 may be a 

40 telephonic dial-up of web server 136 or it might be a long 
and complex path along the internet if web server 136 is 
remote from the originating internet terminal. Web server 
136 is the software which performs the retrieval of screen 
118 from world wide web path 132. 

45 Screen 118 is transferred from web server 136 to Cool 
ICE object 138, wherein it is converted to the internal Cool 
ICE protocol and language. A browser input is opened at 
storage resource 166 via paths 150 and 151. Thus the initial 
service request can be accessed from storage resource 166 

50 during processing up until the final result is transferred back 
to the user. This access readily permits multi-step and 
iterative service request processing, even though the service 
request was transferred as a single internet dialog element. 
This storage technique also provides initially received input 

55 parameters to later steps in the processing of the service 
request. 

Cool ICE object 138 notifies Cool ICE service handler 
156 through the Cool ICE Engine Interface 157 that a 
service request has been received and logged in. The service 

60 request itself is utilized by Cool ICE service handler 156 to 
retrieve a previously stored sequence of data base manage- 
ment system command statements from repository 166. 
Thus, in the general case, a single service request will result 
in the execution of a number of ordered data base manage- 

65 ment system commands. The exact sequence of these com- 
mands is defined by the service request developer as 
explained in more detail below. 
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Service input parameters 170 is prepared from the service 
request itself and from the command sequence stored in 
repository 166 as shown by paths 164 and 165. This list of 
input parameters is actually stored in a dedicated portion of 
repository 166 awaiting processing of the service request. 

Each command statement from repository 166 identified 
with the service request object is sequentially presented to a 
Cool ICE service 168 for processing via path 160. The 
corresponding input parameters 170 is coupled with each 
command statement via path 176 to produce an appropriate 
action of the enterprise data base management system at 
Cool ICE service 168. After the enterprise data base man- 
agement system has responded to a given query, the inter- 
mediate products are stored as entries in HTML document 
172 which is also stored in a dedicated portion of repository 
166. 

After all command statements corresponding to the ser- 
vice request have been processed by the enterprise data base 
management system and HTML document 172 has been 
completed, the result is provided via path 158 to Cool ICE 
Engine Interface 157. Cool ICE object 138 receives the 
browser output via path 150. The response is converted to 
HTML protocol and transferred by web server 136 and 
world wide web path 134 to be presented to the user as a 
modified screen (not shown). 

FIG. 7 is a pictographic drawing 178 of the development 
process for creating a Cool ICE service. HTML document 
180 is created utilizing any commercially available standard 
HTML authoring tool (e.g., Microsoft FrontPage), The 
resulting HTML document 180 is stored as a normal .HTM 
file. This file will be utilized as a template of the service to 
be developed. 

The authoring process moves along path 182 to invoke the 
administration module of the Cool ICE system at element 
184. The new dynamic service is created using HTML 
document 180 stored as a normal .HTM file as a template. 
As HTML document 180 is imported into Cool ICE, 
sequences of script for the beginning and end of the HTML 
code are automatically appended to the service. Required 
images, if any, are also uploaded onto the web server (see 
also FIGS. 5 and 6). The service is edited by inserting 
additional Cool ICE script, as required. A more detailed 
description of the editing process may be found in Cool ICE 
User's Guide, Revision 2.0, available from Unisys Corpo- 
ration and incorporated herein by reference. 

The completed service script is transferred along path 186 
to element 188 for storage. The service is stored as a service 
object in the repository (see also FIGS. 5 and 6). Storage is 
effected within the appropriate category 190 as discussed 
above, along with services 192, 194, and 196 within the 
same category. 

The process proceeds along path 198 to element 200 for 
testing. To perform the testing, the URL for the newly 
created service is entered into the browser of the internet 
terminal, if known. The typical URL is as follows: 

http://machine-name/Cool-ICE/default.asp?Category= 
Examples & Service=FRME+01 If the URL for the new 
service is not known, a list of the available services may be 
determined from the Cool ICE system by specifying the 
Cool ICE URL as follows: 

hup; ^/machlne-name/Coot-ICE 

This call will result in a presentation of a menu containing 
the defined categories. Selecting a category from the list will 
result in a menu for the services defined within that category. 
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The desired service can thus be selected for testing. Selec- 
tion of the service by either means will result in presentation 
of the HTML page as shown at element 200. 

The process proceeds to element 204 via path 202, 

s wherein the HTML page may be enhanced. This is accom- 
plished by exporting the HTML document from the Cool 
ICE administration module to a directory for modification. 
By proceeding back to HTML document 180 via path 208, 
the exported HTML template is available for modification 

ao using a standard HTML authoring tool. After satisfactory 
completion, the finished HTML document is saved for future 
use. 

FIG. 8 is a diagram showing a comparison between 
dialog-based structure 210 and service-based structure 212. 

15 Dialog-based structure 210 is the norm for the typical 
existing proprietary data base management system (e.g., 
Classic MAPPER). The user, normally sitting at a dedicated 
user terminal, transfers output screen 214 to the data base 
management system to request a service. The user terminal 

20 and its normally dedicated link are suspended at element 216 
to permit transfer and operation of the data base manage- 
ment system. The input is validated at element 218, while 
the user terminal and its normally dedicated link remains 
suspended. 

25 The data base management system processes the service 
request at element 220 while the user terminal remains 
suspended. Output occurs at element 222 thereby releasing 
the suspension of the user terminal. Thus, a true dialog is 
effected, because one part of the dialog pair (i.e., the user 

30 terminal) is suspended awaiting response from the data base 
management system. This type of dialog is best accom- 
plished in an environment wherein at least the user terminal 
(or data base management system) is dedicated to the dialog, 
along with the link between user terminal and data base 

35 management system. 

Service-based structure 212 illustrates one of the basic 
constraints of the world wide web protocol. To ensure that 
each of the elements on the world wide web are sufficiently 
independent and to prevent one element from unduly delay- 

40 ing or "hanging-up" another element to which it is coupled 
awaiting a response, the communication protocol forces a 
termination after each transmission. As can be readily seen, 
even the simplest dialog requires at least separate and 
independent transactions or services. The first service, Ser- 

45 vice 224, involves the transmissions of output form 228 
from the internet user terminal. This transmission is imme- 
diately and automatically followed by termination 230 to 
ensure independence of the sender and receiver. 

The second service, Service 226, enables the receiver of 

50 output form 228 to process the request and output an 
appropriate response. The validation of the input at element 
232, processing 234, and output 236 all occur within the 
receiver of output form 228. Immediately and automatically, 
termination 238 follows. Thus, if internet transactions are to 

55 be linked into a true dialog to permit data base management 
functions, the state must be saved from one service to the 
next as taught herein. 

In the preferred mode of the present invention, the state of 
a service is saved in the repository (see also FIGS. 4 and 5) 

60 for use in the next or subsequent services. 

FIG. 9 is a schematic diagram 240 of the preferred mode 
of the present invention showing normal data flow during 
operation, with special attention to the state saving feature. 
Work station 242 is an industry compatible personal com- 

65 puter operating under a commonly available operating sys- 
tem. Browser 244 is a standard, commercially available web 
browser having frames capability. Path 248 is the normal 
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world wide web path between work station 242 and web 
server 254 for the transfer of service requests and input data. 
These transfers are converted by Cool ICE object 256 as 
explained above and sent to Cool ICE Engine Interface 259 
for disposition., 

The service request for data and/or another function is 
converted into the data base management language by 
reference to the service definition portion of repository 262 
through reference along path 276. The actual command 
language of the data base management system is utilized 
over path 286 to access data base 264. The resultant data 
from data base 264 is transferred to Cool ICE object 256 via 
path 288. State manager 260 determines whether the original 
service request requires additional queries to data base 264 
for completion of the dialog. If yes, the resultant data just 
received from data base 264 is transferred via path 284 to 
repository 262 for temporary storage, and the next query is 
initiated over path 286, and the process is repeated. This is 
the state saving pathway which is required to provide the 
user of the Cool ICE system to function in a dialog mode 
over the world wide web. 

Upon receipt of the resultant data from the final query of 
data base 264, state manager 260 determines that the service 
request is now complete. State manager 260 notifies reposi- 
tory 262 via path 280, and the intermediate products are 
retrieved from temporary storage in repository 262 via path 
278 and supplied to Cool ICE service handler 258 via path 
272 for formatting. State manager 260 then clears the 
intermediate products from temporary storage in repository 
262 via path 282. The final response to the service request 
is sent to Cool ICE object 256 via path 270 for manipulation, 
if necessary, and to browser 244 via path 250. 

FIG. 10 is a detailed diagram 440 showing operation of 
the security system during the honoring of a service request. 
The user, operating industry compatible, personalized 
computer, workstation 442, formats a service requests via 
commercially available web browser 444. In the preferred 
mode of the present invention, this is accomplished by then 
making a call to the Cool ICE system. The user simply 
requests access to the Cool ICE home page by transferring 
web browser 444 to the URL of Cool ICE system. After the 
Cool ICE home page has been accessed, one of the buttons 
is clicked requesting a previously defined service request. 
For additional detail on the service request development 
process, see above and the above referenced commonly 
assigned, co-pending U.S. Patent Applications. 

The service request is transferred to web server 454 via 
world wide web path 446. The service request is received by 
Cool ICE object 462 and translated for use within the Cool 
ICE system. The request is referred to the Cool ICE Engine 
Interface 471 via path 464. In the preferred mode of prac- 
ticing the present invention, the Cool ICE Engine Interface 
471 is equivalent to the MAPPER data base management 
system. The service request is passed to Cool ICE Service 
Handler 472 for retrieval of the command language script 
which describes the activities required of the data base 
management system to respond to the service request. 

Cool ICE Service Handler 472 makes an access request of 
Cool ICE service portion 480 of repository 482 via path 478. 
It is within Cool ICE service portion 480 of repository 482 
that the command language script corresponding to the 
service request is stored. The command language script is 
obtained and transferred via path 466 to service handler 472 
for execution. Along with the command language script, a 
security profile, if any, is stored for the service request. As 
explained in the above referenced, commonly assigned, 
co-pending U.S. Patent Application, the security profile, if 
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required, is added to the command language script file at the 
time of service request development by the service request 
developer. This security profile identifies which of the 
potential service requesters may actually be provided with a 

5 complete response. The security profile, if any, is similarly 
transferred to service handler 472 via path 476. 

If no security profile has been identified for the service 
request, service handler 472 allows the execution of the 
command language script received via path 476 through 

ao access of remote database 456 via paths 458 and 460, as 
required. The response is transferred to Cool ICE object 462 
via path 468 for conversion and transfer to workstation 442 
via world wide web path 450. 

However, if a security profile has been identified for the 

15 service request, service handler 462 requests the user to 
provide a user-id via path 470, Cool ICE object 462, and 
world wide web path 452. Service handler 472 awaits a 
response via world wide web path 448, Cool ICE object 462, 
and path 466. Service handler 472 compares the user-id 

20 received to the security profile stored with the command 
language script. If the user matches the security profile, 
access is granted and service handler 472 proceeds as 
described above. If the user does not match with the stored 
security profile, the service request is not executed and the 

25 user is notified via an appropriate message. 

FIG. 11 is a detailed flowchart 300 showing the process 
for authoring a Cool ICE service in SQL utilizing the data 
wizard. Entry is made at element 302. This is accomplished 
by the user who enters from the data wizard request on the 

30 user's standard browser. The user actually clicks on the data 
wizard button of the Cool ICE home page, which appears if 
the user-id indicates that the user is to have service devel- 
opment access to Cool ICE. This causes an HTML page to 
be transmitted to the Cool ICE system requesting the ioi- 

35 tiation of the data wizard script writing tool. The HTML 
page also indicates whether the request is to create a new 
Cool ICE service or to review (and possibly modify, copy, 
etc.) an existing Cool ICE service. 

If the request is to create a new Cool ICE service as 

40 determined by element 306, control is given via path 308 to 
element 312 for selection of the data source. This data source 
may be co-located with the Cool ICE system or may reside 
at some remote location. Tnough it is transparent to the user 
whether the data is co-located, it involves additional script- 

45 ing to fetch data from a remote location. Cool ICE supports 
local databases ODBC (CORE level, 32-bit), Oracle, 
Sybase, Microsoft SQL, and Unisys MAPPER Query Lan- 
guage. Cool ICE supports remote databases Microsoft SQL, 
Informix, ODBC (CORE level, 32-bit drivers), Oracle, 

50 Sybase, Ingres, Unisys MAPPER Query Language, Unisys 
Relational Database Management System (RDMS), and 
Unisys A Series Query Language (ASQL). Up to five 
different data bases may be utilized through the use of the 
JOIN TABIDS option. 

55 The security profile is checked and verified at element 
334. As discussed more fully in the above identified 
co-pending applications, this security profile can specify 
access to a database, a table, or even an individual column 
of data within a table (see also FIG. 13). Element 338 refines 

60 the data base management system query to be used. At that 
point, the security profile may need to be reverified and 
control may be returned to element 334 via path 336. This 
iterative verification of the security profile is necessary as 
the query is refined, because the refining process may 

65 indicate other data elements which must be accessed. Of 
course, this reverification is most likely if the governing 
security profile specifies access to only individual columns 
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within a table. After the security has been completely 
verified, element 334 creates and displays a table from the 
specified data sources. A more complete description con- 
cerning the refining process is found below in reference to 
FIG. 12. 

The completed query is a sequence of command state- 
ments scripted in the SQL language, Cool ICE script, or a 
combination involving Cool ICE reports stored in the reposi- 
tory. It defines all of the data base management system 
functions which must be executed to properly respond to the 
to service request made by the user at the internet terminal. 
This completed query is saved in the repository (see above) 
by element 340. The query may be saved as both a query 
definition service and as a dynamic HTML service along 
path 342 Thus the completed service may be easily called for 
subsequent use. 

Following saving of the completed query definition, path 
344 permits element 350 to set a security profile for the 
service just defined. This security profile specifies which 
user-id(s) may access this service. The service will not 
appear on the Cool ICE main menu or on the data wizard 
service list for any user-id not thus specified as a user of the 
service. The security profile for a given user may be changed 
subsequently as described below in more detail. 

Path 346 permits execution of a selected query service at 
element 352. The user may exit data wizard at element 354 
via path 348. 

When element 306 determines that an initial user's 
request is to view an existing query definition, path 310 
provides control to element 314. If the user-id of the 
requestor matches with the security profile of the exiting 
query definition, element 314 displays the query definition 
by formatting and transmitting an HTML screen to the user 
internet terminal. As explained above, the security profile 
given to the existing query definition, if any, will determine 
whether it will even appear on the user menu. The user is 
then given the option via a menu selection of one of paths 
316, 318, 320, 322, 324, or 326. 

Path 316 permits creation of a new query definition. Path 
318 provides for copying of an existing query definition. 
Path 320 produces opportunity to modify an existing query 
definition. In each of these three cases, path 328 gives 
control to element 312 for creation or modification of the 
query definition in accordance with the process described 
above. 

Path 322 provides for removal of the query definition. In 
this instance, an obsolete query definition may be erased 
from the repository. 

Path 324 is available to change the security profile for a 
given selected query definition. Control is given to element 
350 via path 330 and the security profile is modified as 
discussed above. Path 326 gives the user the opportunity to 
execute an existing query definition. Element 352 receives 
control from path 332 and executes the existing query 
definition as discussed above. 

FIG. 12 is a detailed diagram 356 of the query definition 
refining process wherein elements 358, 360, 376, and 378 
correspond to elements 334, 338, 340, and 336, respectively, 
of FIG. 11 Upon presentation of the selected data sources 
table, the query definition may be refined at element 3608. 
The options available are: 

1. add a where clause that defines up to five conditions for 
retrieving data from the report or table along path 362 
or an order by clause along path 364; 

2. Sort the table or report according to the data in up to 
five columns; 

3. Analyze and summarize selected data in the report or 
table via path 366. For each column a total value, 
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average the data, select a minimum column value, or 
select a maximum column value may be computed. 

4. Perform calculations on the data via path 368. The data 
wizard can compute, compare, and replace numeric 

5 data, character strings, dates, and times in selected 
columns. 

5. Reformat or define how the selected data appears when 
the Cool ICE service for this query definition is 
executed via path 370. Using the reformat option 

10 enables definition of the column order, field size, and 
column headings. 

6. Create a graph of the data via path 374. The definition 
of the graph may be saved as part of the query defini- 
tion. 

15 Basically, refining a query definition is a three-step pro- 
cess. The three steps are: where and order by; analyze, 
calculate, and reformat; and create a graph or selectively 
view any or all columns. The user simply makes the selec- 
tions on the user menu and clicks on the desired result. The 

20 data wizard applies the specific refining action and redis- 
plays the resultant screen. 

FIG. 13 is a detailed flow diagram 380 of the functions 
performed by the Cool ICE administration module (see also 
FIGS. 4, 5, and 9) for query definition. The primary respon- 

25 sibility of Cool ICE administration module 382 is to register 
with the required local and remote data bases needed for the 
query definition. Path 384 provides for such registration. 

In order for registration to take place, Cool ICE admin- 
istration prompts the user with one or more HTML screens 

30 for entry of the data needed to identify and register the data 
bases. For each data base to be utilized, the user must supply 
information such as the TCP/IP address, data base type (e.g., 
ODBC, MQL, etc.), user-id, user password, and logical 
name for this data source within Cool ICE. Access to a 

35 particular data base may be for the entire data base as with 
path 384, only specified tables within the data base as with 
path 386, or only with specified columns with specified 
tables within the data base as with path 388. In each 
instance, the user-id and user password supplied must cor- 

40 respond to the access specified. 

Path 390 permits the user to create a security profile for 
the query definition. It is axiomatic that the user can define 
a security profile which is more restrictive than the user's 
own security profile, but cannot define a less restrictive 

45 profile. As with all Cool ICE security profiles, access may be 
granted by entire data base, by select tables within the data 
base, or by select columns within select tables within the 
data base. 

Security profiles are allocated to individual users via path 

50 392. In a typical application, certain employees might have 
access to the query definition and all of the resulting 
response, whereas others may have access to the query 
definition but have access to only a portion (by table and/or 
column) of the resulting response. Yet others would be 

55 denied any access. 

FIG. 14 is a detailed schematic diagram 394 of query 
definition using the data wizard. The user, at internet work- 
station 396, activates commercially available world wide 
web browser 398 and accesses the Cool ICE homepage via 

60 world wide web paths 406, 408, and 412 using the previ- 
ously defined URL. The Cool ICE homepage has a button 
for calling data wizard 420 for query definition. 

Cool ICE data wizard 420 determines the nature of the 
service request (see also FIG. 11) and begins processing. 

65 Paths 414 and 416 enable Cool ICE administration module 
432 to register the required data bases (see also FIG. 13). 
The resulting SQL script generated by data wizard 420 is 
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transferred to repository 438 via path 430 for storage at 
query definition storage area 436. 

Execution of an existing data wizard scripted query 
definition is accomplished by Cool ICE engine 428 which is 
essentially the MAPPER data base management system in 
the preferred mode of the present invention. The script is 
accessed from storage and transferred to Cool ICE engine 
428 via path 434. Accesses to remote database(s) 422 is via 
world wide web paths 424 and 426. 

The resultant report produced by execution of the query 
definition script is transferred to data wizard 420 via path 
418 for formatting. The response is then transferred to 
service handler 402 via path 410 for transfer via world wide 
web path 412 as an HTML page which is presented to the 
user on workstation 396. 

FIG. 15 is a flow diagram showing operation of the Join 
Service within Cool ICE Data Wizard 500. At element 504, 
the developer specifies up to five tables, up to fifty fields, and 
a defining where clause. These definitions are provided to 
Cool ICE Data Wizard Join 506. The joined resulting data is 
provided to element 508 to permit other data wizard opera- 
tions. The output is produced at element 512. The End user 
has the joined and formatted data available at element 514. 

FIG. 16 is a detailed flow chart showing the operation of 
the join service. Entry is via path 516 which corresponds to 
the output of select data source 312 (see also FIG. 11). Up 
to five tables are selected by the user at element 518. 
Element 520 checks and displays the selected tables. The 
join functions are performed at elements 522 and 524 as 
shown. Path 526 returns control to element 338 (see FIG. 
11). In accordance with the preferred mode of the present 
invention, the data bases in the following formats may be 
joined with the Cool ICE Data Wizard Join Service: 

ODBC; 

RDMS (HMP/IX); 

RDMS (HMP/IX) UniAccess ODBC; 

DMS HMP/IX INFOAccess32 OCBC (level 3.2 or 3.3); 

DMS II HMP/NX— Info Access32 ODBC (level 4.2); 

Oracle; 

Microsoft SQL Server; 
Sybase Adaptive Server; 
Informix; and 
Ingres. 

FIG. 17 is a detailed flow diagram of the Utrace Archi- 
tecture. A client, such as Client A (Application 1) 530, Client 
B (Application 1) 532, or Client C (Application 2) 534 
requests tracing services through UTRACER.DLL 542. The 
client calls a method from CUTracer 536, CUTracer 538, or 
CUTracer 540 to explicitly turn on tracing, unless the tracing 
is implicitly turned on when the CUTracer object reads the 
trace registry settings for the component. 

The activated CUTracer class instantiates an instance of 
the Utrace COM object, and based on information from the 
client, sets client specific properties in the component. The 
client also sets properties of the trace helper class to assist 
in automatic formatting trace messages. The client builds up 
a trace message using the CUTracer class, and then calls oo 
a method to send the message. 

The CUTracer class does formatting as determined by its 
properties, and then invokes one of the IUTrace interface 
methods (i.e., IUTrace 546, IUTrace 548, or IUTrace 550) 
from UTRACE.EXE 544 to trace the message. The Utrace 
component then writes a line of trace information to the trace 
file (i.e., Application 1 Trace File 562 for application 1 or 
Application 2 Trace File 564 for application 2). The activi- 
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ties of the trace session (i.e., trace file open, information 
gathering, and trace file close) are under the direction of the 
application. 

FIG. 18 is a table showing the various registry settings in 
5 accordance with the preferred mode of the present invention. 

FIG. 19 is a flow chart showing the generic trace process. 
Tracing may be initiated manually by client 566 or auto- 
matically by application 568. In either situation, element 570 
turns on the trace process. Parameters for the tracing process 
may be supplied by both the client, via element 572, and by 
the application, via element 574. 

Element 576 initiates the UTrace COM object (see also 
FIG. 17). The specific trace object is built at element 578. 
Element 580 sends the method call message, and element 
582 prepares the class generic formatting. The actual trace is 
15 performed at element 584. The trace data is stored at element 
586. 

FIG. 20A is a table showing the definitions for policy 
trace flags which are stored in a registry value. In addition, 
the application may define its own set of policy flags that are 

20 more appropriate for that application. Through registry 
settings, the policy may apply to all components of the 
application. Alternatively, different policy settings may be 
applied to different components. These policy settings are 
stored in a corresponding registry key. 

25 FIG. 20B is a table showing a typical run-time call. Upon 
encountering this script, the policy for the component is 
queried for the CI 13 TRACE„DETAIL policy flag to see if 
the tracing should actually occur. 

Having thus described the preferred embodiments of the 

3Q present invention, those of skill in the art will be readily able 
to adapt the teachings found herein to yet other embodi- 
ments within the scope of the claims hereto attached. 
We claim: 

1. In a data processing system having a user terminal 
which generates a plurality of software application compo- 

35 nents for accessing a data base management system com- 
prising: 

a trace facility for tracing and debugging said plurality of 
software application components running in a publicly 
accessible digital data communication network 
40 environment, 

wherein each transmission processed in each of said 
plurality of software application components results in 
a termination of a transaction, 

wherein said tracing and debugging are performed based 
45 on values of a plurality of trace flags stored within a 
registry, and 

wherein trace information as a result of tracing said 
plurality of software application components is con- 
verted into a generic format and stored in a common 
50 trace file for subsequent access by a user through said 
data base management system. 

2. The improvement according to claim 1 wherein said 
publicly accessible digital data communication network 
further comprises Internet and wherein said trace facility is 

55 manually activated by said user terminal. 

3. The improvement according to claim 2 wherein said 
user terminal further comprises an industry compatible 
personal computer having a commercially available 
browser. 

60 4. The improvement according to claim 1 wherein said 
data base management system is Classic MAPPER and 
wherein said trace facility is automatically activated by one 
of said plurality of software applications. 
5. An apparatus comprising: 
65 a user terminal which generates a plurality of software 
application components running in a publicly acces- 
sible digital data communication network environment, 
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wherein each transmission processed in each of said 
plurality of software application components results in 
a termination of a transaction, 

a data base management system responsively coupled to 
said user terminal via a publicly accessible digital data 5 
communication network which responds to said plu- 
rality of software application components; and 

a dynamic common trace facility which performs tracing 
of said plurality of software application components 
based on values of a plurality of trace flags stored 10 
within a registry, and then writes trace information as 
a result of said tracing into a common trace file, 
wherein said trace information is converted into a 
generic format before being stored. 

6. The apparatus of claim 5 wherein said publicly acces- 15 
sible digital data communication network further comprises 
Internet. 

7. The apparatus of claim 6 wherein said user terminal 
further comprises an industry compatible personal computer 
containing a web browser. 

8. The apparatus of claim 7 wherein said data base 
management system further comprises the MAPPER data 
base management system. 

9. A method of dynamically tracing a plurality of software 
application components from a user terminal coupled to a 25 
remote data base management system having a data base 
which responds to said plurality of software application 
components comprising: 

providing a generic formatting module; 30 
defining a generic trace policy which identifies actual 

trace operations to be performed; 
defining a plurality of policy trace flags, wherein values of 

said policy trace flags are stored within a registry; 
tracing said plurality of software application components 35 

using said generic trace policy as defined by said policy 

trace flags, 

wherein said plurality of software application components 
are running in a publicly accessible digital data network 
environment, and 40 

wherein each transmission processed in each of said 
plurality of software application components results in 
a termination of a transaction; 

formatting results of said tracing using said generic for- 45 
matting module; and 

writing said formatted results from said tracing into a 
common trace file. 

10. A method according to claim 9 wherein the step of 
defining a plurality of policy trace flags includes defining a 50 
trace identifier which is common to said plurality of soft- 
ware application components. 

11. A method according to claim 10 wherein said publicly 
accessible digital data communication network further com- 
prises world wide web. 55 

12. A method according to claim 11 wherein said user 
terminal further comprises an industry compatible personal 
computer. 



13. A method according to claim 12 wherein said remote 
data base management system further comprises MAPPER 
data base management system. 

14. An apparatus comprising: 

means for permitting a user to create a plurality of 
software application components, 

wherein said plurality of software application components 
are running in a publicly accessible digital data network 
environment, and 

wherein each transmission processed in each of said 
plurality of software application components results in 
a termination of a transaction, 

means responsively coupled to said permitting means via 
a publicly accessible digital data communication net- 
work for responding to said plurality of software appli- 
cation components having a data base management 
system; and 

means for defining a generic trace policy which identifies 
actual trace operations to be performed based on values 
of a plurality of policy trace flags stored within a 
registry; 

means responsively coupled to said permitting means and 
said responding means for tracing said plurality of 
software application components, 

wherein said tracing is performed based on said generic 
trace policy, and 

wherein trace information as a result of said tracing is 
converted into a generic format using a generic for- 
matting module and then stored in a common trace file. 

15. An apparatus according to claim 14 wherein said 
generic trace policy further comprises means for defining 
trace parameters using a plurality of policy trace flags 
including a trace identifier which is common to said plurality 
of software application components. 

16. An apparatus according to claim 15 wherein said 
publicly accessible digital data communication network 
further comprises Internet. 

17. An apparatus according to claim 16 wherein said 
responding means further comprises MAPPER data base 
management system. 

18. An apparatus according to claim 17 wherein said 
permitting means further comprises an industry standard 
personal computer. 

19. An apparatus according to claim 15 wherein said trace 
parameters further comprises a process identifier (PID). 

20. An apparatus according to claim 19 wherein said trace 
parameters further comprises a thread identifier. 

21. An apparatus according to claim 20 wherein said trace 
parameters further comprises a time stamp. 

22. An apparatus according to claim 21 wherein said 
generic formatting module prepares said trace parameters. 

23. An apparatus according to claim 22 wherein said 
generic formatting module stores said trace parameters. 

24. An apparatus according to claim 23 wherein said trace 
policy further comprises a common header file. 
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